Electronic devices are often used to store private user data in digital form. This data can be protected in various ways. For example, an operating system (OS) installed on an electronic device can require authentication procedures to be performed prior to accessing the data (e.g., requiring a user to enter a passphrase before the user can access the data stored on the electronic device). Hard drive encryption software can also be used to encrypt on-device data so that an attacker cannot gain access to the data by simply removing the hard drive and plugging the hard drive into a different machine. The security of data on the electronic device is therefore premised on keeping information secret (e.g., passphrases, cryptographic keys, etc.) so that an attacker cannot discover the secrets and gain access to the sensitive data stored on the electronic device.
Furthermore, when the current OS version on the electronic device needs to be updated (e.g., replaced with an updated OS version), the system software of the electronic device can verify that the updated code was signed with a private signing key that is only known to, and possessed by, a trusted entity (e.g., the manufacturer of the electronic device and/or the OS software). In this manner, the electronic device implicitly trusts all code that is signed by the trusted entity using the private signing key. Notwithstanding the aforementioned security measures, unauthorized entities (or attackers) have still found ways to circumvent these security measures in order to gain access to device secrets.
For example, an attacker can exploit the fact that a particular manufacturer signs a large number of software releases, which increases the probability of one or more of the releases containing a software bug. It only takes one signed software release that contains a bug for the attacker to exploit the bug in order to circumvent a security measure of the electronic device, such as the aforementioned passphrase check. Once the attacker discovers a signed software release containing such a bug, this signed code can be installed on the electronic device (because the code was signed with the private signing key), and the bug in the installed software can be exploited for the purpose of circumventing security measures on the electronic device, thereby allowing the attacker to gain access to device secrets and private on-device data.
Existing approaches that attempt to solve the aforementioned security flaw all suffer from a similar drawback; namely, that the electronic device is reliant on entities and/or information that is external to the electronic device itself to keep on-device secrets secure while allowing updates to the device software. For example, a “whitelist” approach can be used to validate software releases against a list of previously validated code, but this requires a way to keep the whitelist up-to-date and is reliant on an external mechanism to do so. A “blacklist” approach can also be used to define a revocation list of “known-bad software” that is referenced before updating the device software, but the attacker in this scenario can simply restrict communication to the electronic device and prevent the device from updating the blacklist, allowing malicious software to be installed on the device. Signature verification suffers from a similar drawback in that an outside entity in possession of a secret key is required to define which software is to be trusted by the electronic device. This not only requires an infrastructure to manage and sign software updates, but it is also a security flaw because it creates a high-value secret outside of the device, which, when obtained, allows an attacker to access on-device secrets for an entire class of devices.